N95- 17209 




Experience with the EURECA Packet Telemetry 
and 

Packet Telecommand System 
By 

Erik Mose Sprensen and Paolo Ferri 

European Space Agency / European Space Operations Centre 
Darmstadt, Germany 


j, 

^5 ? 




ABSTRACT 

The European Retrieval Carrier (EURECA) was launched 
on its first flight on the 3 1st July 1992 and retrieved on the 
29th of June 1993. EURECA is characterised by several 
new on-board features, most notably Packet telemetry, and 
a partial implementation of packet telecommanding, the first 
ESA packetised spacecraft. Today more than one year after 
the retrieval the data from the EURECA mission has to a 
large extent been analysed and we can present some of the 
interesting results. 

This paper concentrates on the implementation and 
operational experience with the EURECA Packet Telemetry 
and Packet Telecommanding. We already discovered during 
the design of the ground system that the use of packet 
telemetry has major impact on the overall design and that 
processing of packet telemetry may have significant effect 
on the computer loading and sizing. During the mission a 
number of problems were identified with the on-board 
implementation resulting in very strange anomalous 
behaviours. Many of these problems directly violated basic 
assumptions for the design of the ground segment adding to 
the strange behaviour. The paper shows that the design of 
a telemetry packet system should be flexible enough to 
allow a rapid configuration of the telemetry processing in 
order to adapt it to the new situation in case of an on-board 
failure. The experience gained with the EURECA mission 
control should be used to improve ground systems for future 
missions. 
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1. INTRODUCTION 

The European Retrievable Carrier (Eureca) is a reusable 
platform supplying power, cooling, ground communications 
and data processing services to a variety of independently 
operated payloads (ref 1). Fifteen experimental facilities are 
carried to support more than fifty individual experiments. 
The operational altitude was 500 Km. The Operations 
Control Centre (OCC) was at ESA's European Space 
Operations Centre (ESOC) in Darmstadt, West Germany. 


The primary groundstations were at Maspalomas in 
the Canary Islands and Kourou at French Guinea. 
During the deployment and retrieval phases contact 
was maintained via the NASA Communications 
Network and the STS. 

At ESOC, operational data processing was carried out 
on the Eureca Dedicated Computer System (EDCS) 
that hosts the mission-configured Spacecraft Control 
and Operations System (SCOS) (ref 2) and the 
Eureca-Specific Software (ESS) applications. 

The Eureca- A 1 mission has characteristics differing 
quite considerably from those of missions hitherto 
supported at ESOC. One of these is the use of Packet 
Telemetry and Packet Commanding. EURECA was 
the first ESA application of Packet Telemetry and 
Commanding. 

2. WHY PACKET TELEMETRY AND 
COMMANDING FOR EURECA 

Spacecraft previously and currently controlled from 
ESOC all use a time-division multiplexed (TDM) 
telemetry, in which fixed-size subframes are 
generated and downlinked at constant rate. In the 
simplest case a given parameter appears at a fixed 
address in the subframe and this parameter reports the 
value of some on-board physical quantity, sampled in 
principle at the subframe rate. Many spacecraft make 
rather more sophisticated use of TDM telemetry, 
essentially because their operations and on-board 
applications cannot live with the restrictions of fixed 
sampling/fixed telemetry address. Thus innovations 
have appeared such as switchable formats, 
programmable formats and floating formats (this last 
named being an ad hoc packetisation). These 
sophistications illustrate a weakness of TDM 
telemetry, namely its inflexibility of handling a 
variety of on-board data sources, generating data at 
temporally varying rates, possibly as determined by 
an elaborate plan of instrument operations. The 
traditional TDM approach of allocating fixed 
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proportions of the available bandwidth to each source then 
becomes both restrictive and wasteful. 

Eureca is a re-usable spacecraft supporting a different 
payload complement on each flight (15 instruments on the 
first flight). It also has to be assumed that most instruments 
are controlled with "unknown design" and that each 
instrument would require on-board flexibility to cover 
different mission phases and instrument modes. Packet 
Telemetry provides powerful capabilities to satisfy variable 
data rates and configurations, also providing abilities for late 
definition and changes. With Packet Telemetry the source 
can generate observational data when needed, hence the 
occurrence pattern or rate may be selected according to the 
phenomenon being observed. Packet telemetry provides 
variable partitioning of downlink avoiding unnecessary 
loading of resources. Another important considerations was 
that the packet telemetry is a standard where other options 
would have required special development with no or little 
reuse leading inevitable to higher cost in the long turn. 

The Packet telemetry recommendation (ref 3) uses two 
principal data structures, the source packet and the Transfer 
Frame, source packets being multiplexed within transfer 
frames. Each on-board source must label its data packets 
using CCSDS defined headers, although no requirements on 
the contained data are imposed. The transfer frames are of 
fixed length, optimised for high-performance transfer to the 
ground. The concept of Virtual Channels (VCs) also exists, 
to allow separation between data of different priorities, for 
example real-time data needed for operations and non 
time-critical dump of science data stored on board. VCs are 
identified at the transfer frame level. In the case of Eureca 
there are two VCs, VCO and VC1, to handle real time and 
playback data respectively. Playback data is downlinked 
from on-board bubble memory and will contain bulky 
payload data as well as housekeeping data from the 
out-contact periods. 

The Eureca telecommanding system is an hybrid between 
the older command standards (Ref 4) and the new Packet 
command standard (Ref 5). The reason for this lies in the 
way it has been implemented on board. Command decoders 
using the old standard have been used as a basis, but the 
extra services of the packet commanding have been built 
into the on-board computer. Thus when the on-board 
computer is nominally activated, the commanding system 
acts like a packet command system, using a subset of COP 
1 of the standard (ref 5) . If the OB C is off, the old 
standard has to be used. This paper will only concentrate on 
the experience in using the COP-1 Procotol. 

NOTE: In this section, although the word COP-1 is used, 
EURECA has only implemented a subset of the COP-1. The 


EURECA terminology and services are not 
completely compatible with the latest issue of the 
CCSDS recommendation. 

COP-1 is a closed-loop Telecommand Protocol that 
utilises sequential ("go-back-n") retransmission 
techniques to correct Telecommand Blocks that were 
rejected by the spacecraft because of error. COP-1 
allows Telecommand Blocks to be accepted by the 
spacecraft only if they are received in strict sequential 
order. This is controlled by the necessary presence of 
a standard return data report in the telemetry 
downlink, the Command Link Control Word 
(CLCW). A timer is used to cause retransmission of 
a Telecommand Block if the expected response is not 
received, with a limit on the number of automatic 
retransmissions allowed before the higher layer is 
notified that there are problems in sending 
Telecommand Blocks. The retransmis sion mechanism 
ensures that: 

No Telecommand Block is lost 
No Telecommand Block is duplicated 
No Telecommand Block is delivered out of 
sequence 

The COP-1 protocol has also an expedited service. 
This service is used for exceptional spacecraft 
communications. Typically, this service is required 
for recovery in absence of telemetry downlink (i.e no 
CLCW), or during unexpected situations requiring 
unimpaired access to the spacecraft data management 
system. 

3. THE GROUND CONTROL SYSTEM 

The introduction of Packet Telemetry makes it 
possible to define Packet Types, and for each of these 
packet types to define a standard for the format and 
presentation of data in the Packet Data Field. The 
following packet types are defined for Eureca: 
Housekeeping 1, Housekeeping 2, Time, 
Acknowledge, Exception, Report, Acknowledge and 
Private Packets. Housekeeping 1 (HK1) packets are 
similar to the subframes of TDM systems, cont ainin g 
snapshots of on-board parameters which can be 
subjected to limit and other checks and displayed on 
alphanumeric and graphic displays. The other packet 
types are different and require specific processing, 
thus making the processing system more complex. 

One of the major changes going from a TDM to 
Packet Telemetry system is the change to an event 
driven system (packets arrive asynchronously, rather 
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than at fixed format rates). This impacts both design and 
computer loading. 

The Architectural Design of the Eureca Dedicated Computer 
System (EDCS) is based on a Telemetry Processing Chain 
and a Telecommnding Chain. The Telemetry Processing 
Chain consists of a Telemetry Receiver, Telemetry 
Processing Task, Command Verifier, Filing and Display 
Tasks (alphanumeric, graphical displays, report/exception 
displays). The Telecommand Chain consists of the Manual 
C omman ding Stacks, Automatic C ommanding Queues, 
Command Verifier, Command Uplinker, Command Filing 
T ask. Display and Configuration Tasks. The Communication 
between these individual tasks is based on the Buffer 
Manager, a tasks responsible for passing Telemetry and 
Command buffers around the system. Telemetry and 
Command buffers are given to the Buffer Manager and 
asked tasks are informed that a data buffer is available for 
processing. The Buffer Manager does not pass around the 
actual data buffers, only small mailbox messages are send 
to the relevant tasks with a reference to the data buffer. This 
architecture is very convenient for Packet Telemetry, the 
Packets are distributed according to the packet type. If for 
a mission other packet types are required, such architecture 
makes it possible to setup a new task to process these new 
packet types without disturbing the functionality of already 
existing tasks. 

As for a TDM spacecraft, the computer load on a packet 
TM system is dominated by telemetry processing and 
display support (neglecting any project specific 
peculiarities). Commanding tasks account for only a small 
fraction (3-5%) of the load. Two main considerations 
distinguish the load characteristics of the ground computer 
system supporting a packet telemetry Firstly, there will not 
be one format, but a set of packets, of different lengths each 
having different processing needs. Secondly, the packets are 
generated asynchronously, not at a constant rate, so it is 
essential to have a traffic model, which gives a fairly 
realistic representation of average and peak packet rates. In 
the case of Eureca, such models are needed for pass and 
post pass activities, which are quite different. During 
real-time processing (pass operations), the packet rate is 
(worst case) 12/s. This generates a much higher load than 
the rather low daily average data rate (2kbits/s) might lead 
one to suppose. By contrast , to give a TDM example 
Hipparcos (a geostationary spacecraft) has a continuous 
data rate of 23 kbits/s but produces one subframe each c. 
10s. The loading of the Hipparcos Dedicated Computer 
System (HDCS) is comparable to that of the EDCS 
(possibly a little lower) despite the Hipparcos's much higher 
bit rate. Similar as for the ground system the on-board 
system must be carefully analysed and a software system 
budget should establish a clear reference case for on-board 


and space to ground traffic scenario, which can be 
used for system testing. Critical on-board areas are 
computer load, timing of cooperation or dependant 
applications, packet buffer sizes and number of 
packet buffers. 

Data delivery to users is greatly facilitated by use of 
packet telemetry, which already results in 
decommutation according to application ID. This also 
simplifies the provision of security, i.e. protection of 
privacy of datasets. Eureca users require rapid access 
to their data, which rules out the traditional method 
science data delivery, dispatch on magnetic tapes. 

The COP- 1 protocol increases the complication of the 
command uplinker software, which has to handle for 
every telecommand with a number of messages 
coming from different units at the station in addition 
to the telemetry messages from the spacecraft. 
Testing this software in a realistic environment 
became absolutely necessary due to the importance of 
the timing aspects of the problem and this forced 
extension of precious testing time with the spacecraft 
flight model connected to a ground station interface. 

4. THE ON-BOARD SYSTEM 

The large number of independent processors on-board 
EURECA increases the likelihood of unexpected 
behaviours which result in corruption of the format or 
contents of the Telemetry Packet produced. During 
the mission a number of problems were identified 
with the on-board implementation resulting in very 
strange anomalous behaviours. Many of these 
problems directly violated basic assumptions for the 
design of the ground segment adding to the strange 
behaviour. Below is a table listing the problems 
experienced during the mission: 
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TRANSFER FRAMES 


Problem 

Consequence 

On-Ground Detection 

Received a corrupted Transfer 
Frame (already corrupted before 
the FECW was calculated) 

The problem was with a spillover 
with Idle Frames between. 

Ground system reported protocol 
an protocol error because the 
expected spillover data were not 
available. 

Packet Discarded 

Always use the First Header Pointer 
in the Transfer Frame Header as the 
Master to locate the first Packet in 
a Frame. If inconsistent with the 
Packet Length from the last Packet 
in the previous Frame discard this 
Packet and report a protocol error. 

When the on-board Data Handling 
System changes mode from High 
Speed Link to Low Speed Link it 
cannot maintain the Transfer 
Frames proper (spillover etc.) 

As above 

As above 

Received a Transfer Frame with 
two Idle Packets and with a non- 
idle packet between. 

Allowed according to the 
standard. 

Do not assume that an Idle-Packet 
always is at the end of a Transfer 
Frame. 


Prevention 


Ground Testing 


Spacecraft Design. 



PRIMARY HEADERS 


Problem 

Consequence 

On-Ground Detection 

Prevention 

Received Packets where the 
Secondary Header Flag was set to 
1 but the Packet Length Field had 
the value 0 (SH is fixed to 6 
octets for EURECA) 

Ground system detected a 
corrupted packet reported a 
protocol error. 

Time calibration not possible. 

Maintain a list of allowed length of 
each Application ID and check 
every received Packet. 

Check consistency between the 
information in the Primary Header 
and the Packet Length. 

Check the value of the P field in 
the Secondary Header if the P field 
is used. 

Ground testing. 

In one experiment the Source 
Sequence Counter is implemented 
as a 16 Bit Counter instead of the 
14 Bit defined in the standard. 

Ground system reported 
segmentation protocol errors 
because the SSC has been 
extended into the Segmentation 
Flags in the Primary Header. 

Packet discarded. 

Normally build into the packet 
decommutation algorithm. 

Ground testing shall 
check that all 
instruments handles 
correctly the wraparound 
of the SSC. This require 
normally a long test run. 

workaround: Restart 

experiment at regular 
interval. 

In one experiment the Source 
Sequence Counter is shared 
between four different Application 
IDs. 

Ground system reports jumps in 
Source Sequence Counter. 

Accounting for these Application 
IDs not possible. 

Normally build into the packet 
decommutation algorithm. 

Ground testing. 
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Problem 

Consequence 

On-Ground Detection 

Prevention 

General: 

Due to onboard power/cooling 
constraints it is necessary to 
activate/deactivate instruments 
frequently. In such cases the 
experiments resets the Source 
Sequence Counter to 0. 

Allowed according to the 
standard 

The Source Sequence Counter is 
not very useful in these cases. The 
ground design must take into 
account such type of operations 



SECONDARY HEADERS AND TIME CALIBRATION 


Problem 

Consequence 

On-Ground Detection 

Prevention 

Received Secondary Headers 
where the Time Field was shifted 
one octet. 

Proper time calibration cannot be 
performed. 

May be difficult. For real-time 
received telemetry it is possible to 
make a plausibility check against 
current time. However this does not 
work for playback of on-board 
stored Telemetry. In the playback 
case another plausibility checks 
must be implemented. 

Ground testing 

Many experiments have problems 
with the stability of their local 
clocks resulting in: 

Unacceptable drift 

Large jumps in time when they 
synchronize with the Master 
Clock. This can even cause the 
time to jump backwards. 

Proper time calibration cannot 
always be performed. 

In case the time jumps 
backwards this may cause 
problems for the filing system. 
However this depends on the 
design of the filing system. 

As above. 

Design of the overall 
time concept including 
requirements on drifts of 
master and local clocks. 
During ground testing 
verify that the 
implementation is 
according to 
specification. 


5. OPERATIONAL EXPERIENCE WITH 
PACKET TM/TC 

One of the main advantages of packet Tm is that the TM 
sourcE can in principle decide what data to send when to 
the ground. This concept was extensively applied on 
EURECA, and the ground segment and operations concept 
used it as a basic assumption. While this proved to work 
well in the nominal cases, it became a problem in cases of 
on-board failures. In some cases the on-board unit which 
experienced that failure took the wrong decision on what 
TM to send, limiting the visibility to the ground of the 
causes of the failure. Some failures affected the 
functionality of the unit to the extent that the unit stopped 
generating TM or even started an endless loop in which 
event TM packets were generated continuously, 
overflowing the on-board data storage. Interaction between 
the subsystem TM generation and the system level 
decisions taken by DHS in case of specific failures were 
also very difficult to handle. In the case of AOCS special 
application software had to be written within DHS to 


guarantee extended TM generation in case of 
subsystem anomalies. This did not succeed in several 
cases during the flight, and the correct TM coverage 
of critical failures was lost as a consequence. 

The implementation of the packet TM concept had a 
major positive effect on the on-board communications 
between "intelligent" instruments and subsystems and 
the central DHS over the DHS data bus. Low level 
protocol problems in the bus interface units were often 
cured at higher level by the packet transfer protocol. 
Those units which were not able to generate packets 
suffered from the low level problems, causing 
significant complications to the operations. One 
negative aspect of the EURECA implementation of 
packet TM was that the DHS application software was 
not able to read the contents of the TM packets 
generated by the other subsystems or instruments. This 
artificially limited enormously the system level fault 
management capabilities of the DHS. In particular the 
information contained in the Housekeeping packets 
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and the Event packets (Report and Exception) was 
essential to detect and isolate problems with the subsystem 
or instrument which could be easily recovered at system 
level. This limitation of the DHS shifted the system level 
fault management to the ground control, which was in 
most of the cases only able to intervene after several 
hours, due to the limited visibility of the spacecraft from 
the ground stations (about 5% of the mission time). 

The use of the different packet types by the different 
packet TM sources on -board (12 instruments and 2 
subsystems) was not always correctly reflecting the 
definitions imposed by the design specifications. In 
particular an improper use of Report and Exception 
packets was causing some problems in flight operations. 
The ground segment was designed under the assumption 
that Exception packets would only report anomalous 
behaviours, and Report packets would indicate progress or 
completion of nominal activities; in several cases it was 
found out during final system testing or even during flight 
that this clear distinction was not always observed. 

Another clear directive for the design of TM packets was 
that all TM parameters for which direct ground monitoring 
was required should have been included in Housekeeping 
packets. The ground segment was designed on this 
assumption and therefore was not supposed to open and 
process science packets. This rule was also in several cases 
not properly followed and the ground had to work around 
the problem by including some specific science packets in 
the list of TM packets to be processed. This was not trivial 
also due to the fact that no formal documentation was 
available to describe science packets, and the relevant 
information had to be extracted from various sources like 
meetings, private conversations and informal documents. 

The packet TM implementation had a significant impact on 
the operational database preparation. Most of the TM 
parameters were contained in several different 
Housekeeping packets; this had an impact on the size of 
database tables and complicated the handling of derived 
parameters, which had to be defined and inserted in all 
TM packets containing a contributing parameters. A large 
amount of manpower had to be invested in the generation 
of the Event packets database. This was mainly caused by 
the large number of possible event packets (of the order of 
2500 at the end) to be defined, but also to the lack of 
description of these packets in the ATT database. The 
contents description and meaning of each event packet had 
to be extracted in most of the cases directly from the on- 
board software code which was generating it. This manual 
ork had to be repeated every time a new version of the 
application software was generated and copied to ESOC, 
even after launch. 


Event packets were the most powerful tool the flight 
controllers had to monitor the spacecraft and payload 
activities and to identify and diagnose anomalies. The 
lack of AIT database in this area reduced significantly 
the quality of the overall ground testing. 

A final consideration should be made on the 
opportunity to involve flight operations personnel in 
the definition of the contents of Housekeeping packets. 
These packets were originally designed following 
engineering considerations and disregarding 
completely the utilisation during operations. This 
forced a complete redesign of the packets at a later 
stage in the development of the spacecraft, with 
impact on both the AIT/AIV progr amm e and the 
operations preparation. 

For commanding no real problems was encountered 
during flight with this concept. Its flexibility was 
properly exploited by the database editors specially 
designed for this mission in the mission control 
system. The block protocol and the related retry 
mechanism in case of failed uplink verification of a 
TC block worked very well, but were very difficult to 
test and tune before flight. 

6. LESSONS LEARNED 

The following lessons have been learned about packet 
telemetry and telecommand systems from development 
of the Eureca spacecraft control system and during the 
mission: 

1. Sizing of ground and on-board computer 
systems needs to be carried out carefully, 
using a good traffic model for the generation 
of the various packets. 

2. Very careful consideration has to be given to 
matching the design of the spacecraft and 
packet control system to the characteristics of 
packet telemetry. "Fudging "a TDM system 
work with packet telemetry is not advised 
and at the best is likely to be highly 
inefficient 

3. On-Ground Testing must take into account 
the use of Packet Telemetry. This must 
include functional tests to verify 1) all 
implemented features of the Packet Telemetry 
(segmentation etc.), 2) proper wraparound of 
counters, 3) stability of on-board clocks 
(master and slave), 4) performance tests to 
verify on-bard loading of the system in 
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typical operational scenarios. 

Ground system must be able to handle errors in 
the implementation of packet telemetry 1) check 
the consistency of all static fields in transfer 
frames and packets, 2) design the system to be 
robust against implementation errors, 3) design 
the system to minimise the impact on other users 
in case of implementation errors, 4) include 
knowledge of the on-board implementation 
(expected application id's, expected packet lengths 
etc.), 5) provide proper reporting for detected 
errors, 6) give operational staff proper visibility 
of detected errors, 6) provide tools to disable 
error reporting of "known errors" 

The COP-1 protocol has proven to be very 
reliable and is able to recover transmission error 
with minimal operational impact. There have been 
a number of occasion where the COP-1 protocol 
has successfully recovered an error. These cases 
all concerns link degradation, and involved the 
following circumstances: 

During the deployment phase with a bad 
RF link between the Shuttle and 
EURECA 

During the deployment phase where the 
EDCS did not receive a Command 
Acceptance Pattern (CAP) from NASA. 
During ESA ground station passes where 
the spacecraft was configured with the 
wrong antennae. 

During ESA ground passes where 
commanding was executed down to 0° 
elevation (resulting in degradation of the 
telecommand and telemetry links). 
During on-board antenna switch over. 
When the OBC failed to allocate a 
telecommand buffer (due to an OBC 
overload condition). 

Although not all of the above cases were foreseen 
in the design of the COP-1 protocol (in particular 
case 2 and 6) the COP-1 protocol has always 
successfully recovered the error with a maximum 
of two retries. It is also important that during 
EURECA routine operations with a normal link 
budget the COP-1 protocol has never been in 
retry (i.e no transmission errors). 

The design of the commanding system in the 
control centre must consider end-to-end protocols 
(in particular needed for uplinking on-board 


software patches and master schedules) and 
provide elements that makes it possible to 
recover in case of ground failures. 

7. Introduction of Packet Telemetry and 
Commands is a major step towards 
standardisation of on-board and ground 
systems. In order to fully archive this goal it 
will be necessary to define standards 
covering more of the format than that 
specified in present standards. At the very 
least local standards are needed for each 
packet type to avoid proliferation. Ref 7 
describes some current ESA work on this 
topic. 

7. CONCLUSION 

The packet TM/TC concept proved very powerful in 
supporting complex operations of an autonomous low- 
Earth orbiter like EURECA. The system supported a 
heavy downlink and uplink traffic correspon ding to a 
total of 10 million transfer frames containing 35 
million packets and 240000 co mman ds were send. 
Most of the above described problems do not relate to 
the overall concept but to the implementation, which 
suffered in the EURECA mission from the lack of 
previous experience. We have found a number of 
problems with the actual implementation of the Packet 
Telemetry Standard but we have not found fl ^y 
problems with the standard itself 

The lessons learned form this mission could be easily 
taken into consideration in the design of future 
missions applying the same approach to the space- 
ground interface. 
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